FIG. 1 shows an HTTP message 50. The exchange of HTTP messages 50 between an HTTP client 52 and an HTTP server 54 is well known in the art of client-server computing. Various RFCs and other public documents may be consulted for details about the various versions and variations of HTTP. For instance, RFC 2616 defines HTTP version 1.1. According to RFC 2616, an HTTP message 50 that is for an HTTP request has a request line 54, such as “GET/HTTP/1.1”. An HTTP message 50 that is for an HTTP response instead has a status line 56, such as “HTTP/1.1 200 OK”. A request line 54 or status line 56 is usually followed by one or more headers, each consisting of a field name 60 and, depending on the particular header, zero or more field bodies 62. A message 50 may end with a message body 64, depending on the type of request or response. Details relating to delimiters, particular headers, and other features of HTTP messages and HTTP communication can be found elsewhere.
FIG. 2 shows an example HTTP request 80 and an example HTTP response 82. The HTTP client 52 sends request 80 over a data network 84 to the HTTP server 54, which handles the request and returns the response 82. The request 80 includes a request line 87 and a number of headers 88 (some requests also have a message body). The response 82 includes a status line 89, headers 90, and a message body 92. HTTP communications need not travel over a network such as network 84; communication between a local client and a local server is possible, albeit usually through the local system's communications stacks.
A shortcoming with HTTP is that it does not provide for authoring through an HTTP channel. That is, the standard HTTP specifications do not specifically provide for clients to manage resources on servers. There is no way for a client to perform resource management operations like copying resources (e.g., files, documents, etc.), moving resources on a server, setting or obtaining properties of resources on a server, locking resources, and so on. In response to this shortcoming, various public and private extensions to HTTP have been devised.
FIG. 3 shows some method extensions 100 and header extensions 102 of a protocol or extension of HTTP that adds remote authoring functionality on top of HTTP. These extensions are from RFC 2518, which defines “HTTP Extensions for Web Authoring and Versioning”, or “WebDAV”. WebDAV is a superset of HTTP that is sometimes referred to as a protocol, and sometimes referred to as an extension of HTTP. The WebDAV protocol defines conventions, methods 100, and headers 102, for requests and responses that otherwise comply with HTTP. That is, WebDAV requests and responses follow the basic format of HTTP messages (e.g., message 50 in FIG. 1). Technically, some of the verbs in the web authoring methods 100 are defined as valid HTTP verbs, however, their functionality is extended by WebDAV. For example, PUT is part of HTTP, but WebDAV extends its functionality to collections, directories, folders, etc. The same basic HTTP communication rules are used, the same line/field/body delimiters are used, the same error codes may be used, and base HTTP methods 104 and base HTTP headers can appear in WebDAV messages. For example an ordinary HTTP OPTIONS request may be answered by a WebDAV-compliant server with a response that has standard HTTP headers as well as one or more non-standard HTTP headers that indicate the availability of one or more HTTP extensions on the server. In general, this manner of extending HTTP allows servers and clients to handle both base HTTP communications as well as various extensions thereto, even if a remote system does not support an extension that is supported locally; unsupported headers and methods are usually ignored or handled gracefully.
The WebDAV extension to HTTP provides functionality to create, change and move documents on a remote server (typically a web server). WebDAV implementations are useful, among other things, for remotely authoring documents or resources served by a web server. WebDAV implementations can also be used for general access-anywhere web-based file storage. Many operating systems, such as Windows, Linux, and Mac OSX provide built-in client and server support for WebDAV, thus allowing transparent use of files on a WebDAV server somewhat as if they were stored in a local directory.
The methods and headers of WebDAV are fully documented elsewhere, however, the main methods are: PUT—put a resource or collection on the server; DELETE—delete a resource or collection from the server; PROPFIND—retrieve properties (as XML) of a resource; PROPPATCH—change and delete properties of a resource; MKCOL—create collections or directories; COPY—copy a resource from one URI to another on the server; MOVE—move a resource from one URI to another on the server; LOCK—put a lock on a resource; UNLOCK—remove a lock from a resource. Some notable headers (field names) are: destination—specifies a URI as a destination resource for methods such as COPY and MOVE; Lock-Token—specifies a token that identifies a particular lock; and Timeout—specifies a duration of a lock.
It has not previously been recognized that there are certain inefficiencies and weaknesses built into WebDAV that can become significant in certain circumstances. FIG. 4 shows a timeline for a sequence of related authoring requests. Suppose that a user of HTTP client 52 would like to get and lock a resource on HTTP server 54. The user will first direct the client 52 to get a particular resource. The client 52 will generate and transmit a GET request 120 to the server 54. The server 54 handles the GET request 120 and returns an appropriate response 122. The round trip time is the time between client 52's transmission of the GET request 120 and the receipt of response 122. As can be seen in FIG. 4, much of the round trip time can be attributed to the time that it takes for the GET request 120 and the response 122 to traverse the network. If the user also needs to lock the resource obtained by GET request 120, another round of communication is needed: client 52 sends discrete LOCK request 124; LOCK request 124 passes through the network; and the server 54 replies with a response 126 that also crosses the network. The second exchange has its own round trip time that may include significant network transmission time. The total time 128 to meet two related needs of the client 52 (the need to both get and lock a resource) includes the time for two round trips or four network transmissions. Furthermore, the two discrete requests 120, 124 require approximately twice the server overhead as a single request, which might cause further delay if the server is heavily loaded.
Another problem with the example in FIG. 4 is that the requested resource could be modified or locked by another client (or the server 54 itself) between the time that client 52 requests the resource and the time the client 52 is able to obtain a lock on the resource. In other words, another request can affect the resource after it is received by the client 52 but before the client 52 is able to obtain a lock on the resource, which could cause an error or unexpected result.
The atomic nature of WebDAV and the inability of WebDAV clients and servers to use compound or multi-aspect authoring requests with one discrete exchange may have other problems and inconveniences. Without necessity, some embodiments discussed below may alleviate some problems associated with HTTP authoring.